FIG. 1 illustrates a prior art enterprise system 100. AS instances 105 may be web application servers, such as Web AS by SAP AG of Walldorf, Germany. AS instances 105 provide a framework to deploy a variety of business and presentation software packages for use in an enterprise environment. AS instances 105 are installed on one or more machines 110 and grouped into a cluster 115. The cluster 115 of AS instances 105 are provided to service work requests 120 received from client nodes 125. Cluster 115 may further include a message server node 130 supporting a message server 135, a database node 140 supporting a database 145, and a web dispatcher 150.
Each AS instance 105 may include one or more virtual machines (VMs) 155 to interpret programs providing the presentation and business logic to service work requests 120. These VM machines may be JAVAVMs (JVMs) compliant with the JAVA 2 Platform, Standard Edition (J2SE), etc. A VM is an example of a runtime system. A VM is an abstract machine that can include an instruction set, a set of registers, a stack, a heap, and a method area, like a real machine or processor. A VM essentially acts as an interface between program code and the actual processor or hardware platform on which the program code is to be executed.
Web dispatcher 150 implements a load-balancing mechanism distributing work requests 120 from client nodes 125 among machines 110 within cluster 115. Web dispatcher 150 may be one of machines 110 having the task of dispatching work requests 120 among machines 110 of cluster 115 or a stand alone hardware node. Work requests 120 are processed by machines 110 and may subsequently be provided to database node 140. Database node 140 offers up the requested data to machines 110, which in turn process and format the results for display on client nodes 125. Each AS instance 105 may further include its own dispatcher mechanism to distribute work requests 120 assigned to it among its individual VMs 155.
Installation files 160 for installing AS instances 105 may be centrally stored within database 145. To deploy each AS instances 105, installation files 160 are copied from database node 140 to each machine 110 via a network link. Once copied, installation files 160 are installed generating a file system and establishing AS instances 105 on each machine 110. When freshly installed, each AS instance 105 is deployed with a default configuration installation for VMs 155 and the applications and services deployed therewith. AS instances 105 may be operated using the default configuration installation; however, this does not guarantee that all available resources will be utilized optimally or that AS instances 105 will function properly.
Typically, once each AS instance 105 is up and running with the default installation configuration, a user manually configures each AS instance 105. Manual configuration generally requires a sophisticated knowledge about the hardware and OS platforms, as well as, the tasks to be performed by each AS instance 105. The user configuring a default installation configuration may need to determine and input a large number of parameters unique to each AS instance 105 in a time consuming and error prone processes.
Furthermore, the conventional configuration technique with the JAVA stack relies on system-dependent information which is heavily and redundantly distributed across the entire cluster configuration tree. This, for example, makes it impossible to adjust the configuration when system settings (e.g., JAVA home, system name, instance number, host names, etc.) are changed. Also, since system-dependent settings are statically configured within the configuration database, when the system environment changes (e.g., due a system copy), these settings are to be adapted manually, which makes it impossible to move a configuration, as is, from one system to another. Further, there is a high risk of inconsistent configuration of cluster nodes running on the same instance